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Abstract 


The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 
specification defined two stateful options, IA_NA and IA_TA, but did 
not anticipate the development of additional stateful options. 
DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. 
Applications that use IA NA and IA_PD together have revealed issues 
that need to be addressed. This document updates RFCs 3315 and 3633 
to address these issues. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7550. 


Troan, et al. Standards Track [Page 1] 


RFC 7550 Multiple Stateful Options May 2015 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


Troan, et al. Standards Track [Page 2] 


RFC 7550 Multiple Stateful Options May 2015 


Table of Contents 


1. Introduction 3 
2. Conventions 4 
3. Terminology we ds Ba lal aos Se Tat ek TG 4 
4. Handling of Maltiple IA opt Ton. Types ais Bente eas? a 4 
4.1. Placement of Status Codes in an Advertise Message 6 
4.2. Advertise Message Processing by a Client NEEE E Bo og 8 
4.3. T1/T2 Timers .. ah nish Hot. eh Poa wie pce “eo Ds et et ak ea ide See 9 
4.4. Renew and Rebind Méssagės ae a a EO BO a a a a ae a a ea LO 
4.54.1: Renew Messager an w edd mo wai ei aS ah Sores e BO 
pA “Rebind. Messagen saw goon aao es a ee ee See r we L 
Ats Updates- -to Section: 8.1.23 OE REG 3315 22° sors ake a LL 
4.44. Updates to Section 18.1.4 0f RFC 3315.0 b ecs ew poe » I3 
4.4.5. Updates to Section 18.1.8 of RFC 3315 ........ 14 
4.4.6. Updates to Section 18.2.3 of RFC 3315 ........ 16 
4.4.7. Updates to Section 18.2.4 of RFC 3315 ........ 18 
44.58%: Updates to: REC 3633-2 a: de. oe Ge ae Se ae a ae 20 
4.5. Confirm Message . . . top te ; woth RS l 
4.6. Decline Should Not Necessarily Trigger a Release et 2. 2A 
Af Multiple Provisioning Domains . ............. 22 
5. Security Considerations . . s. s s WY Cae Ge LG Be ome Uk we a Se 22 
6. References .. Se Pore swat Pe cee yee cel as SE Be a, a on, 2A 
6.1. Normative References di Nae Ge, a ete ts th wor ede ee E ia AA 
O22. Informative References: 2 29. 2 e a Ae aos Pe Sle Le Se 2S 
Acknowledgements: w ae. “eve a a nds ee a se eo cw 2 BA 
Authors “Addresses: © 20d + gee ee oe ie ee oe Pee ee ee ee am ee 9 SA 
1. Introduction 


DHCPv6 [RFC3315] was written without the expectation that additional 
stateful DHCPv6 options would be developed. DHCPv6é Prefix Delegation 
[RFC3633] since added a new stateful option for Prefix Delegation to 
DHCPv6. Implementation experience of the Customer Edge (CE) router 
model described in [RFC7084] has shown issues with the DHCPv6 
protocol in supporting multiple stateful option types, in particular 
IA_NA (non-temporary addresses) and IA_PD (delegated prefixes). 


This document describes a number of problems encountered with 
coexistence of the IA_NA and IA_PD option types and specifies changes 
to the DHCPv6 protocol to address these problems. 


The intention of this work is to clarify and, where needed, modify 


the DHCPv6 protocol specification to support IA_NA and IA_PD option 
types within a single DHCPv6 session. 
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Note that while IA_TA (temporary addresses) options may be included 
with other IA option type requests, these generally are not renewed 
(there are no T1/T2 times) and have a separate life cycle from IA_NA 
and IA_PD option types. Therefore, the IA_TA option type is mostly 
out of scope for this document. 


The changes described in this document are intended to be 
incorporated in a new revision of the DHCPv6 protocol specification 
[DHCPv6]. 


2. Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Terminology 


In addition to the terminology defined in [RFC3315], [RFC3633], and 
[RFC7227], the following terminology is used in this document: 


Identity Association (IA): Throughout this document, "IA" is used to 
refer to the Identity Association containing addresses or prefixes 
assigned to a client and carried in the IA_NA or IA_PD options, 
respectively. 


IA option types: This is used to generally mean an IA_NA and/or 
TA_PD option. 


Stateful options: Options that require a dynamic binding state per 
client on the server. 


Top-level options: Top-level options are DHCPv6 options that are not 
encapsulated within other options, excluding the Relay Message 
option. Options encapsulated by Relay Message options, but not by 
any other option, are still top-level options, whether they appear 
in a relay agent message or a server message; see [RFC7227]. 


4. Handling of Multiple IA Option Types 


The DHCPv6 specification [RFC3315] was written with the assumption 
that the only stateful options were for assigning addresses. DHCPv6 
Prefix Delegation [RFC3633] describes how to extend the DHCPv6 
protocol to handle prefix delegation, but does not clearly specify 
how the DHCP address assignment and prefix delegation coexist. 
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If a client requests multiple IA option types, but the server is 
configured to only offer a subset of them, the client could react in 
several ways: 


1. Reset the state machine and continue to send Solicit messages, 


2. Create separate DHCP sessions for each IA option type and 
continue to Solicit for the unfulfilled IA options, or 


3. The client could continue with the single session and include the 
unfulfilled IA options in subsequent messages to the server. 


Resetting the state machine and continuing to send Solicit messages 
may result in the client never completing DHCP and is generally not 
considered a good solution. It can also result in a packet storm if 
the client does not appropriately rate limit its sending of Solicit 
messages or if there are many clients on the network. Client 
implementors that follow this approach SHOULD implement the updates 
to RFC 3315 specified in [RFC7083]. 


Creating a separate DHCP session (separate instances of the client 
state machine) per IA option type, while conceptually simple, causes 
a number of issues: additional host resources required to create and 
maintain multiple instances of the state machine in clients, 
additional DHCP protocol traffic, unnecessary duplication of other 
configuration options and the potential for conflict, and divergence 
in that each IA option type specification specifies its ’own’ version 
of the DHCP protocol. 


The single session and state machine allows the client to use the 
best configuration it is able to obtain from a single DHCP server 
during the configuration exchange. Note, however, that the server 
may not be configured to deliver the entire configuration requested 
by the client. In that case, the client could continue to operate 
only using the configuration received, even if other servers can 
provide the missing configuration. In practice, especially in the 
case of handling IA_NA and IA_PD, this situation should be rare or a 
temporary operational error. So, it is more likely for the client to 
get all configuration if it continues, in each subsequent 
configuration exchange, to request all the configuration information 
it is programmed to try to obtain, including any stateful 
configuration options for which no results were returned in previous 
exchanges. 
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One major issue of this last approach is that it is difficult to 
allow it with the current DHCPv6é specifications; in some cases they 
are not clear enough, and in other cases existing restrictions can 


make it impossible. This document introduces some clarifications and 
small modifications to the current specifications to address these 
concerns. 


While all approaches have their own pros and cons, approach number 3 
above SHOULD be used and is the focus of this document because it is 
deemed to work best for common cases of the mixed use of IA_NA and 
TA_PD. But this document does not exclude other approaches. Also, 
in some corner cases it may not be feasible to maintain a single 
DHCPv6 session for both IA_NA and IA_PD. These corner cases are 
beyond the scope of this document and may depend on the network in 
which the client (CE router) is designed to operate and on the 
functions the client is required to perform. 


The sections that follow update RFCs 3315 and 3633 to accommodate the 
recommendation, though many of the changes are also applicable even 
if other approaches are used. 


4.1. Placement of Status Codes in an Advertise Message 


In Reply messages, IA-specific status codes (i.e., NoAddrsAvail, 
NotOnLink, NoBinding, and NoPrefixAvail) are encapsulated in the IA 
option. In Advertise messages though, the NoAddrsAvail code is 
returned at the top level. This makes sense if the client is only 
interested in the assignment of the addresses and the failure case is 
fatal. However, if the client sends both IA_NA and IA_PD options in 
a Solicit message, it is possible that the server will offer some 
prefixes but no addresses, and the client may choose to send a 
Request message to obtain the offered prefixes. In this case, it is 
better if the Status Code option for IA-specific status codes is 
encapsulated in the IA option to indicate that the failure occurred 
for the specific IA. This also makes the NoAddrsAvail and 
NoPrefixAvail Status Code option placement for Advertise messages 
identical to Reply messages. 


In addition, how a server formats the Advertise message when 
addresses are not available has been a point of some confusion and 
implementations seem to vary (some strictly follow RFC 3315 while 
others assumed it was encapsulated in the IA option as for Reply 
messages). 
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We have chosen the following solution: 


Clients MUST handle each of the following Advertise message formats 
when there are no addresses available (even when no other IA option 
types were in the Solicit): 


1. Advertise containing the IA_NAs and/or IA_TAs with an 
encapsulated Status Code option of NoAddrsAvail and no top-level 
Status Code option. 


2. Advertise containing just a top-level Status Code option of 
NoAddrsAvail and no IA_NAs/IA_TAs. 


3. Advertise containing a top-level Status Code option of 
NoAddrsAvail and IA_NAs and/or IA_TAs with a Status Code option 
of NoAddrsAvail. 


Note: Clients MUST handle the last two formats listed above to 
facilitate backward compatibility with the servers that have not been 
updated to this specification. 


See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and 
Section 11.1 of RFC 3633. 


Servers MUST return the Status Code option of NoAddrsAvail 
encapsulated in IA_NA/IA_TA options and MUST NOT return a top-level 
Status Code option of NoAddrsAvail when no addresses will be assigned 
(number 1 in the above list). This means that the Advertise response 
matches the Reply response with respect to the handling of the 
NoAddrsAvail status. 


Replace the following paragraph in RFC 3315, Section 17.2.2: 


If the server will not assign any addresses to any IAs ina 
subsequent Request from the client, the server MUST send an 
Advertise message to the client that includes only a Status 
Code option with code NoAddrsAvail and a status message for 
the user, a Server Identifier option with the server’s DUID, 
and a Client Identifier option with the client’s DUID. 


With the following text (which addresses the existing erratum 
[Err2472]): 


If the server will not assign any addresses to an IA ina 
subsequent Request from the client, the server MUST include 
the IA in the Advertise message with no addresses in the IA 
and a Status Code option encapsulated in the IA containing 
status code NoAddrsAvail. 
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4.2. Advertise Message Processing by a Client 


[RFC3315] specifies that a client must ignore an Advertise message if 
a server will not assign any addresses to a client, and [RFC3633] 
specifies that a client must ignore an Advertise message if a server 
returns the NoPrefixAvail status to a requesting router. Thus, a 
client requesting both IA_NA and IA_PD, with a server that only 
offers either addresses or delegated prefixes, is not supported by 
the current protocol specifications. 


Solution: a client SHOULD accept Advertise messages, even when not 
all IA option types are being offered. And, in this case, the client 
SHOULD include the not offered IA option types in its Request. A 
client SHOULD only ignore an Advertise message when none of the 
requested IA options include offered addresses or delegated prefixes. 
Note that ignored messages MUST still be processed for SOL_MAX_RT and 
INF_MAX_RT options as specified in [RFC7083]. 


Replace Section 17.1.3 of RFC 3315: (existing errata) 


The client MUST ignore any Advertise message that includes a Status 
Code option containing the value NoAddrsAvail, with the exception 
that the client MAY display the associated status message(s) to the 
user. 


With the following text (which addresses the existing erratum 
[Err2471] and includes the changes made by [RFC7083]): 


The client MUST ignore any Advertise message that contains no 
addresses (IAADDR options encapsulated in IA_NA or IA_TA options) 
and no delegated prefixes (IAPREFIX options encapsulated in IA_PD 
options; see RFC 3633) with the exception that the client: 


- MUST process an included SOL_MAX_RT option (RFC 7083) and 
- MUST process an included INF_MAX_RT option (RFC 7083). 


A client can display any associated status message(s) to the user 
or activity log. 


The client ignoring this Advertise message MUST NOT restart the 
Solicit retransmission timer. 
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4. 


3. 


And, replace: 


- The client MAY choose a less-preferred server if that server 
has a better set of advertised parameters, such as the 
available addresses advertised in IAs. 


With: 


- The client MAY choose a less-preferred server if that server has 
a better set of advertised parameters, such as the available set 
of IAs, as well as the set of other configuration options 
advertised. 


And, replace the last paragraph of Section 11.1 of RFC 3633 with the 
following text (which addresses the existing erratum [Err2469]): 


The requesting router MUST ignore any Advertise message that 
contains no addresses (IAADDR options encapsulated in IA_NA or 
IA_TA options) and no delegated prefixes (IAPREFIX options 
encapsulated in IA_PD options; see RFC 3633) with the exception 
that the requesting router: 


- MUST process an included SOL_MAX_RT option (RFC 7083) and 
- MUST process an included INF_MAX_RT option (RFC 7083). 


A client can display any associated status message(s) to the user 
or activity log. 


The requesting router ignoring this Advertise message MUST NOT 
restart the Solicit retransmission timer. 


T1/T2 Timers 


The T1 and T2 times determine when the client will contact the server 
to extend lifetimes of information received in an IA. How should a 
client handle the case where multiple IA options have different T1 
and T2 times? 


In a multiple IA option type model, the T1/T2 times are protocol 
timers that should be independent of the IA options themselves. If 
we were to redo the DHCP protocol from scratch, the T1/T2 times 
should be carried in a separate DHCP option. 


Solution: The server MUST set the T1/T2 times in all IA options ina 
Reply or Advertise message to the same value. To deal with the case 
where servers have not yet been updated to do that, the client MUST 

select a T1 and T2 time from all IA options, which will guarantee 
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that the client will send Renew/Rebind messages not later than at the 
T1/T2 times associated with any of the client’s bindings. 


As an example, if the client receives a Reply with T1_NA of 3600 / 
T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use 
the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of 
0 means that the Renew time is at the client’s discretion, but this 
value cannot be greater than the T2 value (1800). 


The following paragraph should be added to Sections 18.2.1, 18.2.3, 
and 18.2.4 of RFC 3315: 


The T1/T2 times set in each applicable IA option for a Reply MUST 
be the same values across all IAs. The server MUST determine the 
T1/T2 times across all of the applicable client’s bindings in the 
Reply. This facilitates the client being able to renew all of the 
bindings at the same time. 


Note: This additional paragraph has also been included in the revised 
text later in this document for Sections 18.2.3 and 18.2.4 of RFC 
3313: 


Changes for client T1/T2 handling are included in Sections 4.4.3 and 
4.4.4. 


4.4. Renew and Rebind Messages 


This section presents issues with handling multiple IA option types 
in the context of creation and processing the Renew and Rebind 


messages. It also introduces relevant updates to [RFC3315] and 
[RFC3633]. 
4.4.1. Renew Message 


In multiple IA option type models, the client may include multiple IA 
options in the Request message, and the server may create bindings 
only for a subset of the IA options included by the client. For the 
IA options in the Request message for which the server does not 
create the bindings, the server sends the IA options in the Reply 
message with the NoAddrsAvail or NoPrefixAvail status codes. 


The client may accept the bindings created by the server, but may 
desire the other bindings to be created once they become available, 
e.g., when the server configuration is changed. The client that 
accepted the bindings created by the server will periodically send a 
Renew message to extend their lifetimes. However, the Renew message, 
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as described in [RFC3315], does not support the ability for the 
client to extend the lifetimes of the bindings for some IAs, while 
requesting bindings for other IAs. 


Solution: The client, which sends a Renew message to extend the 
lifetimes of the bindings assigned to the client, SHOULD include IA 
options for these bindings as well as IA options for all other 
bindings that the client desires but has been unable to obtain. The 
client and server processing need to be modified. Note that this 
change makes the server’s IA processing of Renew similar to the 
Request processing. 


4.4.2. Rebind Message 


According to Section 4.4.1, the client includes IA options in a Renew 
message for the bindings it desires but has been unable to obtain by 
sending a Request message, apart from the IA options for the existing 
bindings. 


At time T2, the client stops sending Renew messages to the server and 
initiates the Rebind/Reply message exchange with any available 
server. In this case, it should be possible to continue trying to 
obtain new bindings using the Rebind message if the client failed to 
get the response from the server to the Renew message. 


Solution: The client SHOULD continue to include the IA options 
received from the server, and it MAY include additional IA options to 
request creation of the additional bindings. 


4.4.3. Updates to Section 18.1.3 of RFC 3315 
Replace Section 18.1.3 of RFC 3315 with the following text: 


To extend the valid and preferred lifetimes for the addresses 
assigned to an IA, the client sends a Renew message to the server 
from which the addresses were obtained, which includes an IA option 
for the IA whose address lifetimes are to be extended. The client 
includes IA Address options within the IA option for the addresses 
assigned to the IA. The server determines new lifetimes for these 
addresses according to the administrative configuration of the 
server. The server may also add new addresses to the IA. The 
server can remove addresses from the IA by returning IA Address 
options for such addresses with preferred and valid lifetimes set 
to 0. 


The server controls the time at which the client contacts the 
server to extend the lifetimes on assigned addresses through the T1 
and T2 parameters assigned to an IA. However, as the client 
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Renews/Rebinds all IAs from the server at the same time, the client 
MUST select a T1 and T2 time from all IA options, which will 
guarantee that the client will send Renew/Rebind messages not later 
than at the T1/T2 times associated with any of the client’s 
bindings. 


At time T1, the client initiates a Renew/Reply message exchange to 
extend the lifetimes on any addresses in the IA. 


If Tl or T2 had been set to 0 by the server (for an IA_NA) or there 
are no Tl or T2 times (for an IA_TA) in a previous Reply, the 
client may send a Renew or Rebind message, respectively, at the 
client’s discretion. 


The client sets the "msg-type" field to RENEW. The client 
generates a transaction ID and inserts this value in the 
"transaction-id" field. 


The client places the identifier of the destination server ina 
Server Identifier option. 


The client MUST include a Client Identifier option to identify 
itself to the server. The client adds any appropriate options, 
including one or more IA options. 


For IAs to which addresses have been assigned, the client includes 
a corresponding IA option containing an IA Address option for each 
address assigned to the IA. The client MUST NOT include addresses 
in any IA option that the client did not obtain from the server or 
that are no longer valid (that have a valid lifetime of 0). 


The client MAY include an IA option for each binding it desires but 
has been unable to obtain. This IA option MUST NOT contain any 
addresses. However, it MAY contain the IA Address option with the 
"IPv6 address" field set to 0 to indicate the client’s preference 
for the preferred and valid lifetimes for any newly assigned 
addresses. 


The client MUST include an Option Request option (see section 22.7) 
to indicate the options the client is interested in receiving. The 
client MAY include options with data values as hints to the server 
about parameter values the client would like to have returned. 
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4.4. 


4. 


The client transmits the message according to section 14, using the 
following parameters: 


IRT REN_TIMEOUT 

MRT REN_MAX_RT 

MRC 0 

MRD Remaining time until T2 


The message exchange is terminated when time T2 is reached (see 
section 18.1.4), at which time the client begins a Rebind message 
exchange. 


Updates to Section 18.1.4 of RFC 3315 


Replace Section 18.1.4 of RFC 3315 with the following text: 


At time T2 (which will only be reached if the server to which the 
Renew message was sent at time Tl has not responded), the client 
initiates a Rebind/Reply message exchange with any available 
server. 


The client constructs the Rebind message as described in section 
18.1.3 with the following differences: 


- The client sets the "msg-type" field to REBIND. 


- The client does not include the Server Identifier option in the 
Rebind message. 


The client transmits the message according to section 14, using the 
following parameters: 


IRT REB_TIMEOUT 

MRT REB_MAX_RT 

MRC 0 

MRD Remaining time until valid lifetimes of all addresses in 


all IAs have expired 


If all addresses for an IA have expired, the client may choose to 
include this IA without any addresses (or with only a hint for 
lifetimes) in subsequent Rebind messages to indicate that the 
client is interested in assignment of the addresses to this IA. 
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The message exchange is terminated when the valid lifetimes of all 
addresses across all IAs have expired, at which time the client 
uses the Solicit message to locate a new DHCP server and sends a 
Request for the expired IAs to the new server. 


4.4.5. Updates to Section 18.1.8 of RFC 3315 


Replace Section 18.1.8 of RFC 3315 with the following text: 


Upon the receipt of a valid Reply message in response to a Solicit 
(with a Rapid Commit option), Request, Confirm, Renew, Rebind, or 
Information-request message, the client extracts the configuration 
information contained in the Reply. The client MAY choose to 
report any status code or message from the Status Code option in 
the Reply message. 


If the client receives a Reply message with a status code 
containing UnspecFail, the server is indicating that it was unable 
to process the message due to an unspecified failure condition. If 
the client retransmits the original message to the same server to 
retry the desired operation, the client MUST limit the rate at 
which it retransmits the message and limit the duration of the time 
during which it retransmits the message. 


When the client receives a Reply message with a Status Code option 
with the value UseMulticast, the client records the receipt of the 
message and sends subsequent messages to the server through the 
interface on which the message was received using multicast. The 
client resends the original message using multicast. 


When the client receives a NotOnLink status from the server in 
response to a Confirm message, the client performs DHCP server 
solicitation, as described in section 17, and client-initiated 
configuration, as described in section 18. If the client receives 
any Reply messages that do not indicate a NotOnLink status, the 
client can use the addresses in the IA and ignore any messages that 
indicate a NotOnLink status. 


When the client receives a NotOnLink status from the server in 
response to a Request, the client can either reissue the Request 
without specifying any addresses or restart the DHCP server 
discovery process (see section 17). 


The client SHOULD perform duplicate address detection [17] on each 
of the received addresses in any IAs, on which it has not performed 
duplicate address detection during processing of any of the 
previous Reply messages from the server. The client performs the 
duplicate address detection before using the received addresses for 
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the traffic. If any of the addresses are found to be in use on the 
link, the client sends a Decline message to the server for those 
addresses as described in section 18.1.7. 


If the Reply was received in response to a Solicit (with a Rapid 
Commit option), Request, Renew, or Rebind message, the client 
updates the information it has recorded about IAs from the IA 
options contained in the Reply message: 


- Record T1 and T2 times. 


- Add any new addresses in the IA option to the IA as recorded by 
the client. 


- Update lifetimes for any addresses in the IA option that the 
client already has recorded in the IA. 


- Discard any addresses from the IA, as recorded by the client, 
that have a valid lifetime of 0 in the IA Address option. 


- Leave unchanged any information about addresses the client has 
recorded in the IA but that were not included in the IA from the 
server. 


Management of the specific configuration information is detailed in 
the definition of each option in section 22. 


The client examines the status code in each IA individually. If 
the client receives a NoAddrsAvail status code, the client has 
received no usable addresses in the IA. 


If the client can operate with the addresses obtained from the 
server, the client uses addresses and other information from any 
TAs that do not contain a Status Code option with the NoAddrsAvail 
status code. The client MAY include the IAs for which it received 
the NoAddrsAvail status code, with no addresses, in subsequent 
Renew and Rebind messages sent to the server, to retry obtaining 
the addresses for these IAs. 


If the client cannot operate without the addresses for the IAs for 
which it received the NoAddrsAvail status code, the client may try 
another server (perhaps by restarting the DHCP server discovery 
process). 


If the client finds no usable addresses in any of the IAs, it may 
either try another server (perhaps restarting the DHCP server 
discovery process) or use the Information-request message to obtain 
other configuration information only. 
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When the client receives a Reply message in response to a Renew or 
Rebind message, the client: 


- sends a Request message if any of the IAs in the Reply message 


contains the NoBinding status code. The client places IA 
options in this message for only those IAs for which the server 
returned the NoBinding status code in the Reply message. The 


client continues to use other bindings for which the server did 
not return an error. 


- sends a Renew/Rebind if any of the IAs are not in the Reply 
message, but in this case the client MUST limit the rate at 
which it sends these messages, to avoid the Renew/Rebind storm. 


- otherwise accepts the information in the IA. 


When the client receives a valid Reply message in response to a 
Release message, the client considers the Release event completed, 
regardless of the Status Code option(s) returned by the server. 


When the client receives a valid Reply message in response to a 
Decline message, the client considers the Decline event completed, 
regardless of the Status Code option(s) returned by the server. 


4.4.6. Updates to Section 18.2.3 of RFC 3315 
Replace Section 18.2.3 of RFC 3315 with the following text: 


When the server receives a Renew message via unicast from a client 
to which the server has not sent a unicast option, the server 
discards the Renew message and responds with a Reply message 
containing a Status Code option with the value UseMulticast, a 
Server Identifier option containing the server’s DUID, the Client 
Identifier option from the client message, and no other options. 


For each IA in the Renew message from a client, the server locates 
the client’s binding and verifies that the information in the IA 
from the client matches the information stored for that client. 


If the server finds the client entry for the IA, the server sends 
back the IA to the client with new lifetimes and, if applicable, 
T1/T2 times. If the server is unable to extend the lifetimes of an 
address in the IA, the server MAY choose not to include the IA 
Address option for this address. 


The server may choose to change the list of addresses and the 
lifetimes of addresses in IAs that are returned to the client. 
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If the server finds that any of the addresses in the IA are not 
appropriate for the link to which the client is attached, the 
server returns the address to the client with lifetimes of 0. 


For each IA for which the server cannot find a client entry, the 
server has the following choices depending on the server’s policy 
and configuration information: 


- If the server is configured to create new bindings as a result 
of processing Renew messages, the server SHOULD create a binding 
and return the IA with allocated addresses with lifetimes and, 
if applicable, T1/T2 times and other information requested by 
the client. The server MAY use values in the IA Address option 
(if included) as a hint. 


- If the server is configured to create new bindings as a result 
of processing Renew messages, but the server will not assign any 
addresses to an IA, the server returns the IA option containing 
a Status Code option with the NoAddrsAvail status code anda 
status message for a user. 


- If the server does not support creation of new bindings for the 
client sending a Renew message, or if this behavior is disabled 
according to the server’s policy or configuration information, 
the server returns the IA option containing a Status Code option 
with the NoBinding status code and a status message for a user. 


The server constructs a Reply message by setting the "msg-type" 
field to REPLY and copying the transaction ID from the Renew 
message into the "transaction-id" field. 


The server MUST include a Server Identifier option containing the 
server’s DUID and the Client Identifier option from the Renew 
message in the Reply message. 


The server includes other options containing configuration 
information to be returned to the client as described in section 
18.2. 


The T1/T2 times set in each applicable IA option for a Reply MUST 
be the same values across all IAs. The server MUST determine the 
T1/T2 times across all of the applicable client’s bindings in the 
Reply. This facilitates the client being able to renew all of the 
bindings at the same time. 
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4.4.7. Updates to Section 18.2.4 of RFC 3315 
Replace Section 18.2.4 of RFC 3315 with the following text: 


When the server receives a Rebind message that contains an IA 
option from a client, it locates the client’s binding and verifies 
that the information in the IA from the client matches the 
information stored for that client. 


If the server finds the client entry for the IA and the server 
determines that the addresses in the IA are appropriate for the 
link to which the client’s interface is attached according to the 
server’s explicit configuration information, the server SHOULD 
send back the IA to the client with new lifetimes and, if 
applicable, T1/T2 times. If the server is unable to extend the 
lifetimes of an address in the IA, the server MAY choose not to 
include the IA Address option for this address. 


If the server finds that the client entry for the IA and any of 
the addresses are no longer appropriate for the link to which the 
client’s interface is attached according to the server’s explicit 
configuration information, the server returns the address to the 
client with lifetimes of 0. 


If the server cannot find a client entry for the IA, the IA 
contains addresses and the server determines that the addresses in 
the IA are not appropriate for the link to which the client’s 
interface is attached according to the server’s explicit 
configuration information, the server MAY send a Reply message to 
the client containing the client’s IA, with the lifetimes for the 
addresses in the IA set to 0. This Reply constitutes an explicit 
notification to the client that the addresses in the IA are no 
longer valid. In this situation, if the server does not send a 
Reply message, it silently discards the Rebind message. 


Otherwise, for each IA for which the server cannot find a client 
entry, the server has the following choices depending on the 
server’s policy and configuration information: 


- If the server is configured to create new bindings as a result 
of processing Rebind messages (also see the note about the 
Rapid Commit option below), the server SHOULD create a binding 
and return the IA with allocated addresses with lifetimes and, 
if applicable, T1/T2 times and other information requested by 
the client. The server MAY use values in the IA Address option 
(if included) as a hint. 
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- If the server is configured to create new bindings as a result 
of processing Rebind messages, but the server will not assign 
any addresses to an IA, the server returns the IA option 
containing a Status Code option with the NoAddrsAvail status 
code and a status message for a user. 


- If the server does not support creation of new bindings for the 
client sending a Rebind message, or if this behavior is 
disabled according to the server’s policy or configuration 
information, the server returns the IA option containing a 
Status Code option with the NoBinding status code and a status 
message for a user. 


When the server creates new bindings for the IA, it is possible 
that other servers also create bindings as a result of receiving 
the same Rebind message. This is the same issue as in the 
Discussion under "Rapid Commit Option"; see section 22.14. 
Therefore, the server SHOULD only create new bindings during 
processing of a Rebind message if the server is configured to 
respond with a Reply message to a Solicit message containing the 
Rapid Commit option. 


The server constructs a Reply message by setting the "msg-type" 
field to REPLY and copying the transaction ID from the Rebind 
message into the "transaction-id" field. 


The server MUST include a Server Identifier option containing the 
server’s DUID and the Client Identifier option from the Rebind 
message in the Reply message. 


The server includes other options containing configuration 
information to be returned to the client as described in section 
18.2. 


The T1/T2 times set in each applicable IA option for a Reply MUST 
be the same values across all IAs. The server MUST determine the 
T1/T2 times across all of the applicable client’s bindings in the 
Reply. This facilitates the client being able to renew all of the 
bindings at the same time. 
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4.4.8. Updates to RFC 3633 
Replace the following text in Section 12.1 of RFC 3633: 


Each prefix has valid and preferred lifetimes whose durations are 
specified in the IA_PD Prefix option for that prefix. The 
requesting router uses Renew and Rebind messages to request the 
extension of the lifetimes of a delegated prefix. 


With: 


Each prefix has valid and preferred lifetimes whose durations are 
specified in the IA_PD Prefix option for that prefix. The 
requesting router uses Renew and Rebind messages to request the 
extension of the lifetimes of a delegated prefix. 


The requesting router MAY include IA_PD options without any 
prefixes, i.e., without an IA Prefix option or with the IPv6 
prefix field of the IA Prefix option set to 0, in a Renew or 
Rebind message to obtain bindings it desires but has been unable 
to obtain. The requesting router MAY set the "prefix-length" 
field of the IA Prefix option as a hint to the server. As in 
[RFC3315], the requesting router MAY also provide lifetime hints 
in the IA Prefix option. 


Replace the following text in Section 12.2 of RFC 3633: 


The delegating router behaves as follows when it cannot find a 
binding for the requesting router’s IA_PD: 


With: 


For the Renew or Rebind, if the IA_PD contains no IA Prefix option 
or it contains an IA Prefix option with the IPv6 prefix field set 
to 0, the delegating router SHOULD assign prefixes to the IA_PD 
according to the delegating router’s explicit configuration 
information. In this case, if the IA_PD contains an IA Prefix 
option with the IPv6 prefix field set to 0, the delegating router 
MAY use the value in the "prefix-length" field of the IA Prefix 
option as a hint for the length of the prefixes to be assigned. 
The delegating router MAY also respect lifetime hints provided by 
the requesting router in the IA Prefix option. 


The delegating router behaves as follows when it cannot find a 
binding for the requesting router’s IA_PD containing prefixes: 
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4.5. Confirm Message 


The Confirm message, as described in [RFC3315], is specific to 
address assignment. It allows a server without a binding to reply to 
the message, under the assumption that the server only needs 
knowledge about the prefix(es) on the link, to inform the client that 
the address is likely valid or not. This message is sent when, e.g., 
the client has moved and needs to validate its addresses. Not all 
bindings can be validated by servers and the Confirm message provides 
for this by specifying that a server that is unable to determine the 
on-link status MUST NOT send a Reply. 


Note: Confirm has a specific meaning and does not overload Renew/ 


Rebind. It also has a lower processing cost as the server does NOT 
need to extend lease times or otherwise send back other configuration 
options. 


The Confirm message is used by the client to verify that it has not 
moved to a different link. For IAs with addresses, the mechanism 
used to verify if a client has moved or not is by matching the link’s 
on-link prefix(es) (typically a /64) against the prefix-length first 
bits of the addresses provided by the client in the IA_NA or IA_TA 
TA-types. As a consequence, Confirm can only be used when the client 
has an IA with an address(es) (IA_NA or IA_TA). 


A client MUST have a binding including an IA with addresses to use 
the Confirm message. A client with IAs with addresses as well as 
other IA-types MAY, depending on the IA-type, use the Confirm message 
to detect if the client has moved to a different link. A client that 
does not have a binding with an IA with addresses MUST use the Rebind 
message instead. 


IA_PD requires verification that the delegating router (server) has 
the binding for the IAs. In that case, a requesting router (client) 
MUST use the Rebind message in place of the Confirm message and it 
MUST include all of its bindings, even address IAs. 


Note that Section 18.1.2 of RFC 3315 states that a client MUST 
initiate a Confirm when it may have moved to a new link. This is 
relaxed to a SHOULD as a client may have determined whether it has or 
has not moved using other techniques, such as described in [RFC6059]. 
And, as stated above, a client with delegated prefixes MUST send a 
Rebind instead of a Confirm. 
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4. 


4. 


6. 


6. 


6. Decline Should Not Necessarily Trigger a Release 


Some client implementations have been found to send a Release message 
for other bindings they may have received after they determine a 
conflict and have correctly sent a Decline message for the 
conflicting address(es). 


A client SHOULD NOT send a Release message for other bindings it may 
have received just because it sent a Decline message. The client 
SHOULD retain the non-conflicting bindings. The client SHOULD treat 
the failure to acquire a binding as a result of the conflict, to be 
equivalent to not having received the binding, insofar as it behaves 
when sending Renew and Rebind messages. 


7. Multiple Provisioning Domains 


This document has assumed that all DHCP servers on a network are ina 
single provisioning domain and thus should be "equal" in the service 
that they offer. This was also assumed by [RFC3315] and [RFC3633]. 


One could envision a network where the DHCP servers are in multiple 
provisioning domains, and it may be desirable to have the DHCP client 
obtain different IA-types from different provisioning domains. Howa 
client detects the multiple provisioning domains and how it would 
interact with the multiple servers in these different domains is 
outside the scope of this document (see [MPVD-ARCH] and 
[DHCPv6—-SUPPORT]). 


Security Considerations 
There are no new security considerations pertaining to this document. 
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